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^ ( 57 > A bstract: A method and an arrangement are disclosed for authenticat-ing a commodity of value delivered from a closed network 
w as a digital message (201 ) to a mobile terminal. The digital message (201 ) has a predefined format that comprises fields (204, 205) 
^ for network-generated values (206, 208). Authenticating involves generating (31 1, 406) a code value according to a time-dependent 
rule, so that the.generated code value depends on the moment of time when the digital message will be transmitted. The generated 
O code value is inserted (311, 406) into a certain first field (204) in the digital message, which first field has a predefined role that 
^ is other than conveying code values. Another value that represents message transmission time is inserted (407) into a second field 
^ (205) in the digital message. 
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Method and arrangement for authenticating a commodity of value delivered as 
a digital message 

5 The invention concerns generally the technology of electronically delivering rela- 
tively short and compact messages that represent a commodity of value. Especially 
the invention concerns the problem of how to ensure that such a message, when pre- 
sented for inspection, is an authentic one and not an illegal copy. 

10 Electronically delivering various tickets, discount coupons and corresponding 

commodities of value in the form of SMS messages (Short Message Service), MMS 
messages (Multimedia Message Service) and similar compact, well-defined messag- 
ing formats is rapidly gaining popularity. As an example we may consider the 
known way of ordering and delivering public transport tickets (such as tram or bus 

15 tickets) to the mobile telephones of individual users. In fig. 1 we assume that the 
user of a mobile telephone 101 wants to order an electronically deliverable bus 
ticket. The mobile telephone 101 has a wireless communication connection with a 
base transceiver station 102, from which there is a further connection to a core net- 
work 103 of which an SMSC (Short Message Service Center) 104 constitutes a part. 

20 A ticket application server 105 is arranged to have a communication connection 
with the SMSC. Conveying an order message from the mobile telephone 101 
through the base transceiver station 102 and the SMSC 104 to the ticket application 
server 105 is schematically represented in fig. 1 as a series of steps ©, <D and ®. 
After having received the order message the ticket application server 105 generates 

25 an electronic ticket and sends it back to the mobile telephone that ordered it. Con- 
veying a ticket back to the mobile telephone 101 is shown as steps ®, © and ®. 

Charging for the electronically delivered ticket is most straightforwardly accom- 
plished by adding a certain fixed price to the telephone bill of the user of the mobile 

30 telephone 101 . However, after the user has received the ticket message into his mo- 
bile telephone, it is usually possible for him to forward a copy of the ticket message 
to another mobile telephone, like that of a friend who took the same bus. The price 
for just sending another SMS message is typically considerably lower than the 
ticket price that was charged of the original recipient of the ticket message. A temp- 

35 tation quickly arises to cheat the system by ordering a single ticket for one of a 

group of persons and distributing copies of the original ticket as ordinary SMS mes- 
sages to the other members of the group. 
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It is of principal importance for the arrangement of fig. 1 to be plausible that it is 
possible to verify the authenticity of a ticket message at the moment when it is pre- 
sented for inspection at the user's mobile telephone. A known way of providing au- 
thenticity is to rely on the correctness of the sender information that constitutes a 
5 part of the ticket message. During the process of conveying an SMS message to- 
wards the mobile telephone of a user the network adds the telephone number of the 
sender to the message. An off-the-shelf mobile telephone does not include any 
means for forging the sender information in a received SMS message, so an ille- 
gally forwarded copy can be recognized by noting that its sender is not the ticket 
10 application server. 

The reliability of checking the sender is undermined by certain mobile telephone 
models having a feature that was originally introduced in good faith in order to en- 
hance user-friendliness. The user of the mobile telephone can use a freely selectable 
1 5 alphanumeric string as the identifier of an entry in the directory of stored names and 
numbers. On the other hand said certain mobile telephone models check the 
sender's number from a received SMS message, and if the number matches that of a 
named entry in the directory, they only display the "name" or identifier of that entry 
as the sender of the message. So if we assume that the telephone number of the 
20 ticket application server is 123456 and Tom instructs his mobile telephone to store 
Eve's number as belonging to somebody named "123456", the following scheme 
becomes possible: Eve orders and receives an electronic ticket and forwards an ille- 
gal copy of it to Tom. When Tom's mobile telephone is inspected, it contains a re- 
ceived SMS message, which the mobile telephone only displays as having been re- 
25 ceived from "123456". In other words Tom's illegal copy that he received from Eve 
appears to be an authentic ticket message directly received from the ticket applica- 
tion server. 

In general, various approaches are known for authenticating electronically distrib- 
uted messages. Their drawbacks regarding applicability to the above-described 
problem usually involve complexity either in required hardware or in resulting mes- 
sage content or both. If a relatively short message must represent a ticket, it should 
be easy both for ordinary users and for ticket inspectors to perceive it as one. Elabo- 
rate alphanumeric code strings in the message tend to raise a suspicion of the sys- 
tem being complicated and difficult to use. Additionally for an inspector to be able 
to quickly and unambiguously verify the meaning of a complicated code string re- 
quires that the inspector carries along an electronic reader and verifier device. The 
same is true if the message contains some kind of a bar code that the mobile tele- 
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phone can show on its display, which is one of the suggested message authentica- 
tion techniques. 

A reference publication GB 2 361 570 is known to describe a general-purpose elec- 
5 tronic ticket delivery system, in which the ticket is delivered as an SMS message or 
in a browser-readable format. The SMS solution discussed in said publication is 
especially prone to the fraud scheme described earlier. 

Another known prior art publication is WO 96/06508, which presents a general- 
10 purpose method for reliably identifying the originator of an SMS message. The 
drawback of this scheme is that it requires modifications to the standardised basic 
operation of conveying SMS messages, because it involves using at least two differ- 
ent addresses in calling a Short Message Services Centre. 

15 It is an objective of the invention to provide a method and an arrangement that en- 
sure easy and reliable authentication of commodities of value that were delivered 
electronically in the form of digital messages. It is especially an aim of the inven- 
tion that authentication should require only little, if any, extra investment in system 
hardware. 

20 

The objectives of the invention are achieved by adding a time-dependent extension 
to the telephone number that the message transmission system includes into the 
message as the number of the sender. 

25 A method according to the invention has the characteristic features that are recited 
in the independent patent claim directed to a method. 

The invention applies also to an arrangement, the characteristic features of which 
are recited in the independent patent claim directed to an arrangement. 

30 

Various embodiments of the invention are described in the depending claims. 

The invention is based on the insight that cheating in the way described above is 
only possible if the telephone number of the ticket application server is constant, so 
35 that the potential cheater can store it beforehand into his mobile telephone (or corre- 
sponding mobile telecommunication device) as an identifier of his accomplice. 
Every time when the telephone number of the ticket application server changes, the 
cheater must reprogram his mobile telephone. By making the telephone number of 
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the ticket application server to change very often it is possible to make it difficult 

zr 01 m : cheater to fouow - ***** m «- «* «« of p - 

Md «"» 1» a message it may be possMe to apply , 

Z Strategy ^ ,0 0ther fidd than just the sender'sTele- 

pnone number. 



fier value or identifier values that the network adds into an electronically delivered 

10 ZTfi ^ ^ Certai » ^ e «*««<» locations " 

10 been defined to constitute a part of a field in a tiansmitted message bu, are not ne - 
essardy needed for the Emission of information when the invention is no T 

network *° " ."fT ** ^ 316 "w re >^ * »»L 

network-generated value in a weU-defmed field of the message, so that the message 

becomes self-sustaining regarding verification: for someone who knows me rul 

15 accordmg to which the changing values behave, it suffices to compare me foments 

~ hlT '° S ° me 0ther &ld fa "» »»"» 10 « tether the 

message has been appropriately generated and delivered. 

20 ££TJ2f htf0rW ^ ^ " h the field for the 

tior to ^ * C ° mpriSeS reIatiTC| y ^aracter loca- 

tions o reckon with exceptionally long telephone numbers used in certain systems 
Hthe tdephone number assigned to a ticket application server is not as long Z Z 

u s eTin^ 7 ° f " Umber Md ' * e *~ ^ >°cationsCnt 

field in r y ^ eXtenSi ° m ' ^ 3150 C0ITelate with * e value of anoL 
the time value that is mserted mto the message as transmission time. 

30 SaTo^T- " ™ CODSidered 38 ctoacteri ^ of *e invention are set 
u?con~! " Cl3imS ' ^ inVenti ° n ^ both as to 

ZZZ T "? , meth ° d ° f ° Perati0n ' t0gether Phonal objects and 

effic eX T' T" ta ""^ fr ° m f ° UOW ^ ^n of spe- 
cific embodiments when read in connection with the accompanying drawings. 

35 F.g.l ill^apriorartsempforelectiomcaltyorderinganddetiveringbus 
ticket messages, 6 . 

fig. 2 illustrates a principle of using message parts according to the present in- 
vention. 
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fig. 3a illustrates a process of exchanging messages according to an embodi- 
ment of the present invention, 
- fig. 3b illustrates a process of exchanging messages according to another 
embodiment of the present invention, 
5 fig. 4 illustrates the operation of a ticket application server according to an em- 
bodiment of the invention, 
fig. 5 illustrates the operation of an intelligent messaging gateway according to 

an embodiment of the invention and 
fig. 6 illustrates certain structural aspects of a ticket application server accord- 
10 ing to an embodiment of the invention. 

The exemplary embodiments of the invention presented in this patent application 
are not to be interpreted to pose limitations to the applicability of the appended 
claims. The verb "to comprise" is used in this patent application as an open limita- 
15 tion that does not exclude the existence of also unrecited features. The features re- 
cited in depending claims are mutually freely combinable unless otherwise explic- 
itly stated. 

Fig. 2 illustrates schematically a message 201, which we may designate as a multi- 
20 media message for the sake of generality. Features of the messages that are impor- 
tant to the invention are that it is electronically deliverable from a network to the 
terminals of individual users and that it has a well-defined and standardized struc- 
ture that makes it acceptable and usable for an extremely wide population of mobile 
terminal users. A further feature of the message 201, which is also important to the 
25 present invention, is that its standardized composition defines a network-generated 
part 202 in addition to a user-defined part 203. Considering the widely used SMS 
message as an example, the network-defined part 202 consists of the parameter val- 
ues that a network (typically an SMSC) adds to the message, while the user-defined 
part 203 consists of the (originally maximum of 160) payload characters that a user 
30 or a message-generating computer program at a content provider's server puts in. 

The network-generated part 202 typically comprises fields, of which fields 204 and 
205 are shown in fig. 2, into which the network inserts certain values. We assume 
that at least one of these fields has a certain maximum length that has been selected 
35 to accommodate the longest possible values that can be inserted into that field, with 
some marginal so that typically the whole length of the field is not needed. As an 
example we may say that field 204 is a field for the sender's telephone number. 
Telephone numbers of various lengths appear in different telephone systems around 
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the world, so the length of the sender's number field 204 must have been selected to 
accommodate also relatively long telephone numbers. Typically when the present 
invention is applied, a telephone number that identifies a ticket application server 
(or other instance that is to generate messages that represent a commodity of value) 
is shorter than the maximum length of the field 204, so after said telephone number 
has been inserted as a field value 206, spare space 207 remains in the field 204. 
Again as an exemplary assumption only we assume mat the length of the spare 
space 207 corresponds to three alphanumeric characters. 

Another field 205 also appears in the network-generated part 202 of the message 
201. We assume that field 205 is the transmission time field, into which the SMSC 
should insert a value 208 that represents the moment of time at which the message 
was originally sent by its sender. 

15 According to a preferable embodiment of the invention, the spare space 207 of the 
sender number field 204 is used to carry a code, the value of which has a certain re- 
lationship to the transmission time value 208 in the appropriate field 205. Taken our 
exemplary assumption of the spare space 207 being three characters long, an easy 
option would be to insert a certain fixed character into the spare space 207, followed 
20 (or preceded) by a two-digit number that matches the minute count, i.e. the two- 
digit number that represents minutes, in the transmission time value 208. Another 
option would be to select said two digits to match the second count in the transmis- 
sion time value 208. A third option would be to use two digits of the spare space 
207 to match the minute count and a third digit to match the number that represents 
25 tens of seconds in the transmission time value 208. It is not important to the inven- 
tion, what is the exact way of mapping the transmission time value into a code value 
in the spare space 207; the following considerations should anyway be taken into 
account: 



30 * The mapping algorithm should make the code value to change often enough to 
make it difficult for a potential cheater to follow. The cheating mechanism ex- 
plained earlier requires the cheater to store into his mobile telephone a whole new 
identifier string as the name of his accomplice before forwarding the honestly ob- 
tained ticket message. It is reasonable to assume that making the code value change 

35 once per minute is enough to curtail at least large-scale cheating. 

* The mapping algorithm should be robust against typically occurring time jitter 
and transitional phenomena in the operation of the network devices. If two different 
devices or processes are responsible for generating the transmission time value and 
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the code value, it should be ensured that they synchronize to each other tightly 
enough so that no contradictory value pairs (that would suggest that cheating had 
« been attempted) are generated at the first place. 
* It is advantageous if the mapping algorithm changes, even relativaly slightly, 
5 every now and then so that a potential cheater would be confused. For example if 
the minute count approach is used, there could be a certain fixed offset value that is 
agreed upon e.g. once a week: this week the two digits in the code match the trans- 
mission time minute count plus 1 1, next week it is the minute count minus 05, and 
so on. It is easy to understand that the way of changing the algorithm should be kept 
10 secret from everybody else than those who have the task of running the system 
and/or checking the validity of delivered ticket messages. 

The message may naturally include also other parts and other fields than just those 
shown in fig. 2. If there is not enough spare space in one previously determined 

15 field and/or if it is considered advantageous for increasing security, code values can 
also be distributed into more than one field. It is likewise possible to make a single 
code value depend on more than one other value in more than one other field. In the 
process of defining a completely new message format it would naturally be possible 
to define a dedicated code value field for the insertion of a code value; however it is 

20 a major advantage of the present invention that the code value is "smuggled" in a 
previously defined field, moreover so that every ordinary mobile terminal will han- 
dle and display the code value in an exactly similar way with absolutely no addi- 
tional definitions for message handling. The mobile terminals are not even aware of 
there being any code values involved: they will just handle and display the code 

25 value of the present invention as a part of the value that belongs to the appropriate 
field, which is field 204 in fig. 2. 

Fig. 3a illustrates a process of exchanging messages in a system that comprises a 
mobile terminal, an SMSC that implements the so-called CIMD protocol (Computer 

30 Interface to Message Distribution), a messaging gateway and a ticket application. At 
step 301 the terminal generates a ticket ordering message as a response of a user 
telling the terminal to do so. At step 302 the terminal transmits the message, and at 
step 303 the SMSC receives it. Forwarding the message further towards the ticket 
application may involve certain processing 304 at the SMSC, after which a further 

35 transmit/receive step 305 and 306 takes place between the SMSC and the messaging 
gateway. The latter inspects the incoming message at step 307 enough to find out 
that it is a ticket ordering message, and passes it further to the ticket application in 
steps 308 and 309. The ticket application generates the ordered ticket message at 
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step 310. Up to this point the operation proceeds exactly like in known prior art 
electronic ticketing applications. 

At step 31 1 the ticket application generates an authentication code that is to be 
added to the ticket message generated at the previous step. Certain more detailed 
ways of generating the code wiU be described later. At step 312 the ticket applica- 
tion transmits the completed ticket message to the messaging gateway, which re- 
ceives it at step 313 and selects, by using appropriate known methods, the SMSC 
through which the ticket message should be delivered to the terminal that ordered it. 

A feature of the CIMD protocol is that the SMSC does not need to receive a 
sender's telephone number from the application that generated a message or the 
gateway that forwarded it to the SMSC: the SMSC has been configured to otherwise 
know a sender's telephone number that it adds to the message as a part of the proc- 
ess of sending the message towards the terminal. It is possible to provide a sender's 
telephone number to the SMSC according to CIMD, but the SMSC will still use the 
configured number and only add the number that came from the application server 
into the sender's number field after the configured number. In order not to have the 
same sender's number repeated twice in the message, the messaging gateway - after 
having recognized the appropriate SMSC as one that implements CIMD - strips off 
the actual telephone number value from the message at step 315 before sending the 
message to the SMSC at step 316. The SMSC receives the message at step 317 and 
executes its conventional processing at step 318: as a part of the last-mentioned it 
takes the code value that remained in the sender's number field after step 3 15 and 
appends it to the end of the sender's number field of the final message. Steps 319 
and 320 represent transmitting the ticket message from the SMSC to the mobile 
terminal in a known way. 

Fig. 3b is otherwise the same as fig. 3a, but now we assume that the SMSC imple- 
ments the so-called Content Gateway interface towards message-generating applica- 
tions in the network. An important difference to CIMD arrangements is that accord- 
ing to the Content Gateway specifications, the SMSC will not use any configured 
numbers but will accept and use any sender's number that came with the messsage 
from an application server. Steps 301 to 314 take place exactly in the same way as 
35 m fig. 3a. However, after noticing now at step 314 that the SMSC implements Con- 
tent Gateway rather than CIMD, the messaging gateway now preserves at step 315' 
the contents of the sender's number field as they were in the message that came 
from the ticket application. Step 318' proceeds in the SMSC according to the Con- 
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tent Gateway specifications, so the SMSC reads the whole contents of the sender's 
number from the message it received from the messaging gateway at step 317 and 
< reuses it as such in the message it transmits to the mobile terminal at step 3 19. 

5 Fig. 4 illustrates the operation of a ticket-generating application according to an 
embodiment of the invention. At step 401 the application receives a ticket order 
message from an SMSC, typically through a messaging gateway. At step 402 the 
application extracts the sender's telephone number or corresponding sender identifi- 
cation from the order message and stores it for later use as an identifier of the in- 

10 tended recipient of a generated ticket message. At step 403 the application generates 
the actual ticket message according to some preprogrammed instructions that de- 
scribe how a ticket message should look like and what should it contain. At step 404 
the application inserts the sender identification extracted at step 402 into the mes- 
sage as an identifier of the intended recipient. At step 405 the application takes its 

15 own telephone number or corresponding identifier and inserts it into an appropriate 
sender identification field in the ticket message as a prefix of a complete identifier 
value. Up to this point the process has executed itself similarly as in prior art elec- 
tronic ticketing applications. 

20 According to the invention, at step 406 the application reads a code value and in- 
serts it into the sender identification field in the ticket message as a suffix that com- 
plements the prefix inserted at step 405 to constitute a complete identifier value. If 
we assume that the code value is simply some part of the number string that indi- 
cates current time, possibly altered with a fixed offset, an advantageous way of exe- 

25 cuting step 406 is to read current time from a local clock, extract the appropriate 
numbers from the time value read, refer to a database for finding the currently valid 
offset value, perform the summing (or other calculational) operation between the 
extracted numbers and the offset, and write the result into the ticket message under 
construction. If run-time calculations are to be avoided and/or if the relationship be- 

30 tween a time reading and a corresponding code value is more intricate than a pure 
sum, the database may also include a look-up table prepared beforehand, from 
which the application finds directly a modified code value by using the local time 
reading as a key. 

35 At step 407 the application reads once more (if necessary) the local time value and 
inserts it into an appropriate field in the ticket message as an indicator of original 
message transmission time. At step 408 the application transmits the completed 
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ticket message towards an SMSC, typically through a message gateway. Steps 407 
and 408 are again similar to corresponding steps known from prior art. 

Kg 5 .illustrates the operation of a message gateway functionality according to an 
5 embodiment of the invention when it conveys a completed ticket message from a 
ticket-generating application towards an SMSC. At step 501 the message gateway 

reK 7Tj?* meSSa8e fom •«> « ^p 502 it selects the appro- 

priate SMSC according to certain rules. Typically there is a default SMSC for each 

j"™' <° a «*a» telecommunication system and the identity of the SMSC can 

to S ^ SUbSCliberS antemati0naI M0Me **■»**» 

fo typ,cally the message gateway reads the recipient identifier at step 502 and uses 

some stmple logic to select the appropriate SMSC. Steps 501 and 502 take place ac- 
cording to practices known from prior art. 

15 At step 503 the message gateway checks, whether the selected SMSC runs CIMD or 
not. lo be more general, we may say that at step 503 message gateway checks 
whether the selected SMSC runs a messaging protocol that wj on," s a » 

20 wm^t , k ° r 48 SdeCted SMSC ™" 3 me ™ ~> «** 

20 winch « „ posstble to send a complete sender identifier to the SMSC together with 

the message. A positive finding at step 503, which means that CIMD or a corre- 

spondmg protocol is in use, causes a transition to step 504 at which the message 

gateway deletes the prefix part from the sender identifier drat the application has in- 

25 ™ " S t0 Und<!IStand * a ' meSSage S * te ™y need ««» unambiguous 
25 preprogrammed mictions of how to decide the number of characters to be oe- 

leted; assuring our example of always having three characters in the suffix an un- 
nb«n. instruction may he as simpte as to delete all but tire three last characters 
in a sender identifier string. 

30 A negative finding at step 503 results in a transition to step 505, into which the 
process abo goes after having executed step 504 when needed. Step 505 is a 
ti^ghtforward transmitting step a. which the ticket message is transmitted towards 
the appropriately selected SMSC. 
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methods or methods that at the priority date of this patent application are still to be 
invented are used for charging. 

Fig. 6 is a general block diagram of a system 601 according to an embodiment of 
the invention, in which the message gateway functionality 602 has been integrated 
into a single system with the ticket-generating application 603. At the disposal of 
the latter is a database 604, which can be used for various purposes. Closest of these 
to the present invention is the use of the database 604 as a storage of the currently 
valid code value. The system includes a web interface 605 through which it is pos- 
sible to examine and change certain configuration information stored in the database 
604. There may also be direct connections for exchanging information between the 
web interface 605 on one hand and the message gateway functionality 602 and the 
ticket-generating application 603 on the other hand. As a way of adrninstering the 
database 604 there is a collection of scripts 606, some of which may have been con- 
figured to execute automatically at the fulfilment of certain criteria while others 
must be manually triggered through the web interface 605. 

Illustrating all functionalities of fig. 6 in an exemplary way as existing within a sin- 
gle system 601 does not exclude other possible implementations. Parts of the sys- 
tem may be implemented even very far from each other, physically in clearly sepa- 
rate systems, as long as the communication connections between the different func- 
tionalities are realised appropriately. For example, it is relatively common that a 
message gateway functionality exists as a standalone system that serves to selec- 
tively connect a number of SMSCs with a number of application servers that run a 
wide variation of different service applications that utilize messaging. 

In the description above we have repeatedly referred to "tickets" and "ticket genera- 
tion" as an application of the invention. However, the applicability of the invention 
is not limited to tickets in the sense of admission tickets or travel tickets. The con- 
cept of a "ticket" must be understood widely to cover all such instants where a user 
must or may have at his possession some commodity of value, which ultimately is 
just a piece of information that proves that the user has committed a certain transac- 
tion in a prescribed manner. 

We have also mainly described an embodiment of the invention where the code 
value is derived from the transmission time of the ticket message and inserted into 
the sender identification (sender's telephone number) field, while the transmission 
time is inserted into the well-defined transmission time field of the same message. 



WO 2004/015917 



12 



PCT/FI2003/000597 



In pnnciple it is possible to use only the transmission time field for the transmission 
of both the transmission time and the code value, if the system is allowed to slightly 
break the conventional rules of handling the transmission time field. An example of ' 
tins land is to make the ticket-generating application manipulate the transmission . 
time value so that the minute count and second count would always be the same, or 
differ from each other by the currently valid offset value, in validly issued ticket 
messages. Even if a cheater found out that this week the proof of authentication is 
the fact that the second count is seven more than the minute count in the transmis- 
sion time value, he would have hard times trying to time the transmission of an ille- 
gal copy to his accomplice exactly on the correct second. 
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Claims 

1 . A method for authenticating a commodity of value delivered from a closed 
. network as a digital message (201) to a mobile terminal, which digital message 

(201) has a predefined format that comprises fields (204, 205) for network- 
generated values (206, 208), characterized in that the method comprises the steps 
of: 

- generating (311, 406) a code value according to a time-dependent rule, so that the 
generated code value depends on the moment of time when the digital message will 
be transmitted, 

- inserting (311, 406) the generated code value into a certain first field (204) in the 
digital message, which first field has a predefined role that is other than conveying 
code values, and 

- inserting (407) a value that represents message transmission time into a second 
field (205) in the digital message. 

2. A method according to claim 1, characterized in that the step of inserting 
(311, 406) the generated code value into a certain first field (204) in the digital mes- 
sage comprises the substeps of: 

- inserting (405) into said first field (204) an identifier (206) of a service for 
generating and delivering commodities of value, which identifier (206) is smaller in 
size than a total space available in said first field (204), and 

- additionally inserting (311, 406) the generated code value into said first field (204) 
as a suffix to said identifier (206). 

3. A method according to claim 2, characterized in that it additionally com- 
prises the steps of: 

a) finding out (502, 503), whether the digital message is to be handled according to 
a first communications protocol that will involve using a preconfigured default 
identifier in an identifier field of the digital message and adding potentially existing 
message-contained identifiers after said preconfigured default identifier, and 

b) in the case of a positive finding at step a), stripping (504) from said digital mes- 
sage said identifier of a service for generating and delivering commodities of value, 
before handling said digital message according to said first protocol. 

4. A method according to claim 1, characterized in that the step of generating 
(311, 406) a code value according to a time-dependent rule comprises the substeps 
of: 
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- obtaining a string of digits that represents a transmission time of the digital mes- 
sage and 

- taking a subset of the digits in said string of digits as the code value. 

5 5. A method according to claim 4, characterized in that the step of taking a sub- 
set of the digits in said string of digits as the code value involves taking a pair of 
digits that represent a minute count. 

6. A method according to claim 4, characterized in that the step of taking a sub- 
10 set of the digits in said string of digits as the code value involves taking a pair of 

digits that represent a second count. 

7. A method according to claim 1, characterized in that the step of generating 
(311, 406) a code value according to a time-dependent rule comprises the substeps 

15 of: 

- obtaining a string of digits that represents a transmission time of the digital mes- 
sage, 

- taking a subset of the digits in said string of digits and 

- summing a predefined offset value to the number represented by said subset of 
20 digits to obtain the code value. 

8. An arrangement (601) for generating and delivering authenticated commodi- 
ties of value that are to be delivered from a closed network as digital messages to 
mobile terminals, which digital messages have a predefined format (201) that com- 

25 prises fields (204, 205) for network-generated values (206, 208), characterized in 
that the arrangement comprises: 

- means (603, 604) for generating a code value according to a time-dependent rule, 
so that a generated code value is arranged to depend on the moment of time when a 
digital message will be transmitted, 

30 - means (603) for inserting a generated code value into a certain first field in a digi- 
tal message that will be transmitted, which first field has a predefined role that is 
other than conveying code values, and 

- means (603) for inserting a value that represents message transmission time into a 
second field in a digital message that will be transmitted. 



35 



9. An arrangement according to claim 8, characterized in that it comprises: 
- a commodity-generating application (603) for generating commodities of value 



and 
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jy- 

- coupled to said commodity-generating application (603) a message gateway func- 
tionality (602) for delivering generated commodities of value as digital messages to 
messaging centers for further delivery. 

5 10. An arrangement according to claim 9, characterized in that said commodity- 
generating application (603) is arranged to insert into a first field in generated digi- 
tal messages an identifier of a service for generating and delivering commodities of 
value, which identifier is smaller in size than a total space available in said first 
W field, and to additionally insert a generated code value into said first field as a suffix 

1 0 to said identifier. 

j 11. An arrangement according to claim 10, characterized in that said message 

gateway functionality (602) is arranged to: 

- find out, whether a digital message that is to be delivered to a certain messaging 
15 center is to be handled there according to a first communications protocol that will 

| involve using a preconfigured default identifier in an identifier field of the digital 

message and adding potentially existing message-contained identifiers after said 
| preconfigured default identifier, and 

- strip a part of the contents of an identifier field from digital messages that will be 
20 handled according to said first protocol, before delivering such digital messages to 

messaging centers. 
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